Simplified representation of XML schema structures

ABSTRACT

A software development system and method are provided. The system includes a transform component to convert a schema file into a simplified graphical data representation that coincides with a data representation associated with an underlying instance document. A viewing component displays the simplified graphical data representation.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication Ser. No. 60/868,676 filed on Dec. 5, 2006, entitled “SCHEMASTRUCTURE TRANSFORMATION” the entirety of which is incorporated hereinby reference.

BACKGROUND

Extensible Markup Language (XML) is a common data language employed forvarious applications such as website development and other applicationstypically designed for the Internet. Generally, XML is considered amarkup language for documents containing structured information.Structured information includes both content (words, pictures, and soforth) and some indication of what role that content plays (for example,content in a section heading has a different meaning from content in afootnote, which means something different than content in a figurecaption or content in a database table, and so forth). Almost alldocuments have some structure. Thus, a markup language such as XMLprovides a mechanism to identify structures in a document, where the XMLspecification defines a standard way to add markup to documents. Anotheraspect of XML is referred to as XSD which is an XML based language thatdefines validation rules for XML files, where XSD can be employed forXML Schema Definition. Generally, XSD is an XML based language whichimplies that XSD statements are written in XML files. One importantfunction of XSD is that it defines validation rules for XML files,meaning that XSD can be utilized to replace Document Type Definitions(DTD), which is another language for defining XML validation rules.

Since the structure of XML files and XSD definitions is defined bytextual data and statements, tools for manipulating such languages havenot developed along a similar path such as traditional code-based modelsfor developing source code for example. For instance, code-based modelstypically operate with object classes where tools have developed overtime to create desired software functionality. Although XML and XSD typedeclarations may have some similarity to previous code-based models andclass structures, the differences with code-based models are such thatXML/XSD tools over the last several years have developed according to adifferent path offering different types of functionality than code-basedtools.

In one case, W3C XML is a general-purpose markup language used to encodedata in a structured, human-readable format that can be understood &authored by both people and computers. By itself, XML imposes nopredefined structure—the structure of the data is left to the producerand consumer to agree on. In another case, XML Schema is an XML languagethat can be used to describe those XML structures and the constraints onrespective contents in a formal way, so that producers and consumers canhave an explicit, well-defined metadata contract for data exchange.Since this formal description (e.g., metadata) is itself XML, it can beproduced, consumed & manipulated with the same APIs and tools that areused for the XML the metadata describes.

In another aspect, XML Schema is a complex language with many detailsand nuances. While many developers are familiar with the use of XML toencode data, far fewer of them are familiar with the syntax and use ofXML Schema to describe the metadata. Also, some tend to think in termsof the structure of the data that the schema is describing, yet they arerequired to express this structure using the XML Schema language whichhas a different and only loosely related structure. Existing GraphicalUser Interface (GUI) tools for working with XML Schema files typicallyprovide a direct graphical representation of the contents of the XMLSchema, not the structure of the XML data it describes. Since manydevelopers tend to think in terms of their own data, not the minutia ofthe XML schema language, this makes the XML schema difficult tounderstand and produce.

SUMMARY

The following presents a simplified summary in order to provide a basicunderstanding of some aspects described herein. This summary is not anextensive overview nor is intended to identify key/critical elements orto delineate the scope of the various aspects described herein. Its solepurpose is to present some concepts in a simplified form as a prelude tothe more detailed description that is presented later.

A developer tool and interface is provided that transforms data in onerepresentation to a simplified graphical view that is structured to dataassociated with an underlying instance document. A graphicalrepresentation of data in a schema format, for example, is provided thatmirrors or conforms to the shape of XML data the schema describes. Thisprovides a simplified view of the schema by removing extraneous details(i.e., visual “noise”) relating to the XML Schema language. Bysimplifying the view in this manner, a developer can quickly observe anoverview of what the XML Schema describes and then drill down into thenuances of the XML Schema language itself as desired. Thus, thevisualization provided in the view enables developers to work in theschema language yet maintain semblance of the underlying instanceproduced by the schema. Since most developers are familiar with theinstance document or file, the visualization facilitates more efficientsoftware development.

To the accomplishment of the foregoing and related ends, certainillustrative aspects are described herein in connection with thefollowing description and the annexed drawings. These aspects areindicative of various ways which can be practiced, all of which areintended to be covered herein. Other advantages and novel features maybecome apparent from the following detailed description when consideredin conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram illustrating a data transform anddevelopment system.

FIG. 2 illustrates and example transform on an XSD file representationinto a simplified XSD file representation that conforms to an underlyingXML instance document.

FIG. 3 illustrates an exemplary XML instance file.

FIG. 4 illustrates a prior art representation of an XSD file thatdescribes the instance document depicted in FIG. 3.

FIG. 5 illustrates a simplified graphical representation that provides aviewing structure similar in graphical form to the instance documentdepicted in FIG. 3.

FIG. 6 illustrates an alternative simplified graphical representationthat provides a viewing structure similar in graphical form to theinstance document depicted in FIG. 3.

FIG. 7 illustrates an exemplary XML instance file.

FIG. 8 illustrates an exemplary process for transforming data to asimplified graphical representation.

FIG. 9 is a schematic block diagram illustrating a suitable operatingenvironment.

FIG. 10 is a schematic block diagram of a sample-computing environment.

DETAILED DESCRIPTION

A software development system and method are provided. The systemincludes a transform component to convert a schema file into asimplified graphical data representation that coincides with a datarepresentation associated with an underlying instance document. Aviewing component displays the simplified graphical data representation.The transform component can be provided as part of an integrateddevelopment environment (IDE) to facilitate design of XML schemas andfiles. The method includes loading a schema file into a first datastructure and transforming the first data structure into a second datastructure, where the second data structure provides a view thatcoincides graphically with a shape of an instance document. The instancedocument can be an XML file, for example and the first data structurecan be an XSD file, for example.

As used in this application, the terms “component,” “transform,”“schema,” and the like are intended to refer to a computer-relatedentity, either hardware, a combination of hardware and software,software, or software in execution. For example, a component may be, butis not limited to being, a process running on a processor, a processor,an object, an executable, a thread of execution, a program, and/or acomputer. By way of illustration, both an application running on aserver and the server can be a component. One or more components mayreside within a process and/or thread of execution and a component maybe localized on one computer and/or distributed between two or morecomputers. Also, these components can execute from various computerreadable media having various data structures stored thereon. Thecomponents may communicate via local and/or remote processes such as inaccordance with a signal having one or more data packets (e.g. data fromone component interacting with another component in a local system,distributed system, and/or across a network such as the Internet withother systems via the signal).

Referring initially to FIG. 1, a data transform and development system100 is illustrated. The system 100 includes a transform component 110that inputs a schema file 120 or first data structure and transforms orconverts the schema file to a simplified or second data structure at aviewing component 130. The viewing component 130 can be provided as partof a development system interface that operates the transform component110 and processes the schema file 120. The transform of the schema file120 is to provide a view of a schema that is structured or shaped forviewing in a form that is similar or mirrors the structure of a relatedinstance file 140, where the instance file is the actual coderepresentation that is produced from the processing of the schema file120 in a schema language. For example, the schema file 120 could be anXSD file and the instance file 140 could be an XML file. Thus, thetransform component 110 converts a representation of the schema file 120so it correlates to and appears graphically in nature to an underlyingrepresentation or structure of the instance file 140 when viewed at 130.

In one aspect, the system 100 provides a developer tool and interfacethat transforms or converts data in one representation to a simplifieddata view at 130 that is structured to data associated with theunderlying instance document 140. Although the instance document 140 isnot operated upon by the transform component 110, the view of the schemafile 120 provided at 130 coincides or has a shape that is similar innature to the instance document 140. The viewing component 130 providesa graphical representation of data in a schema format, for example, thatmirrors the shape of XML data the schema 120 describes. This provides asimplified view of the schema 120 by removing extraneous details (i.e.,visual “noise”) relating to the XML Schema language. By simplifying theview in this manner, a developer can quickly observe an overview of whatthe XML Schema 120 describes, and easily work with the nuances of theXML Schema language itself as needed. Thus, the visualization providedin the view at 130 enables developers to work in the schema language yetmaintain semblance or appearance of the underlying instance produced bythe schema 120. Since most developers are familiar with the instancedocument or file 140, the visualization facilitates more efficientsoftware development.

In another aspect, the system 100 provides a platform for schemadevelopment. The system includes means for transforming a schema file(transform component 110) into a simplified graphical datarepresentation that coincides with a data representation associated withan underlying instance document 140. The system also includes means forviewing the simplified graphical data representation (viewing component130). In one aspect, the system 100 can be provided as part of anIntegrated Development Environment (IDE), in one example. An IDEprovides a programming environment that has been packaged as anapplication program, typically consisting of a code editor, a compiler,a debugger, and a graphical user interface (GUI) builder. The IDE may bea standalone application or may be included as part of one or moreexisting and compatible applications. For instance, the JAVA programminglanguage, for example, can be used within common office applications,which makes it possible to write a JAVA program within the officeapplication. Typically, IDEs provide a user-friendly framework for manymodern programming languages, such as Visual Basic, Java, andPowerBuilder, for example. Often, IDEs are employed for developing XMLor HTML applications utilized in Web site applications. For example,many developers design Web sites via an IDE application for Web sitedevelopment that automates many of the tasks involved.

As can be appreciated, various software tools (not shown) can beprovided with the system 100 in addition to the transform component 110and the viewing component 130. Such tools which can be part of an IDEenable developers to design XML document instances, Schemas, such asDTDs, Schematron, or XML Schemas (XSD), XSLT for transformations, XSL-FOfor prepress applications, XLink and XPath expressions, various queriesusing any of a range of querying languages or grammars, CSS stylesheets,Scripts (e.g., Perl, Python, Omnimark, and so forth), as well as othersoftware components for example.

The software tools provide graphical user interfaces around the filesand fragments that come out of the end of the development effort, andcan include a Schema editor, an XSLT editor, a Stylesheet editor, andone or more Script development tools, for example. The IDE that supportssuch tools provides an infrastructure that can include a Parser, an XSLTtransformation engine, a Browser, an XML (document) editor among otherfeatures. The development environment should enable applications to workwith accepted standards, such as W3C XML, DOM3, and SAX, for example.Other tools that can be provided include data content managementsystems, systems or components for data-binding XML into Java classes(or other bindings), a Web application server, and Web servicesdevelopment tools, for example.

Before proceeding it is noted that the system components and toolsdescribed above can be provided as part of a Graphical User Interface(GUI) to interact with the user or other components such as any type ofapplication that sends, retrieves, processes, and/or manipulates data,receives, displays, formats, and/or communicates data, and/orfacilitates operation of the system. For example, such interfaces canalso be associated with an engine, server, client, editor tool or webbrowser although other type applications can be utilized.

The GUI can include a display having one or more display objects (notshown) for manipulating data including such aspects as configurableicons, buttons, sliders, input boxes, selection options, menus, tabs andso forth having multiple configurable dimensions, shapes, colors, text,data and sounds to facilitate operations with the profile and/or thedevice. In addition, the GUI can also include a plurality of otherinputs or controls for adjusting, manipulating, and configuring one ormore aspects. This can include receiving user commands from a mouse,keyboard, speech input, web site, remote web service and/or other devicesuch as a camera or video input to affect or modify operations of theGUI. For example, in addition to providing drag and drop operations,speech or facial recognition technologies can be employed to controlwhen or how data is presented to the user. The data can be updated andstored in substantially any format although formats such as XML can beemployed to capture user controls and instructions.

Referring now to FIG. 2, a system 200 illustrates an example transformon an XSD file representation into a simplified XSD file representationthat conforms to an underlying XML instance document. The system 200includes an XSD file 210 that is transformed into a simplified format ofXSD 220. Such transforms or conversions in into the simplified data form220 can be provided in accordance with the components and toolsdescribed above with respect to FIG. 1. The XSD file 210 is an XML-basedlanguage that defines validation rules for XML files. The acronym XSDstands for XML Schema Definition, where XML represents Extensible MarkupLanguage. Generally, XSD is an XML based-language, meaning than XSDstatements will be written in XML files. In one aspect, XSD definesvalidation rules for XML files, meaning that XSD can be used to replaceDTD, which is another language for defining XML validation rules.

As shown, the simplified format of XSD 220 has a graphical form 230 thatconforms, resembles, or mirrors a data form 240 represented in an XMLinstance document 250. The XML schema represented by the XSD file 210 istypically a single file or collection of files that serve as theframework for defining the data content, format, and structure of an XMLdocument. A well-written schema expresses agreed upon vocabularies andallows computers to validate the data against the rules written todescribe the data. The schema provides a means for defining thestructure and content of XML documents. While a schema describes thecontent and structure of an XML document, the XML instance document 250includes the actual data. The schema represented by the XSD 210, andinstance document 250, are generally separate where the instancedocument is frequently validated against the schema to ensure thecontents and structure are correct. It is to be appreciated thatalthough these examples show a transform from an XSD format 210 to asimplified format 220 which represents an XML instance 250, that othertransforms are possible. For example, a schema 210 could be representedin another language than XSD that conforms graphically in structure todata that is some other format than XML employed in the instancedocument 250. Thus, substantially any type of transform that convertsdata in a schema format to graphically conform to an underlying instanceformat can be employed.

It is noted that the graphical form 230 that conforms to the structure240 provides a structure that is simplified in nature having less XSDlanguage constructs visible and organized to resemble the form 240. Suchresemblance, conformance, or mirroring can take on many forms. This caninclude providing the simplified form 230 with similar types ofindentations, component organizations, component orderings, or othercomponent alignments that make viewing of the simplified format of XSD220 to appear in a similar structural form as the instance document 250.This can also include removing (from the developers view but not fromthe file 210) language nuances such as complex type declarationstatements or other statements that tend to obscure the visual structureof the instance document 250. In general, developers have a workingknowledge of the structure of the instance document 250 but areconstrained by the language in the XSD file 210 to generate thestructure. By providing the transform to the simplified form 220,developers can appreciate the underlying visual structure of theinstance form 240 yet still develop applications that utilize the schemalanguage represented in this example by the XSD file 210.

In another aspect that is described in more detail below with respect toFIG. 6, components such as compositors can be displayed in thesimplified form 230 representing an alternative view. The compositorsare presented outside of the underlying graphical structure and hint atmore of the complexities of the XSD language while still allowingdevelopers to view the simplified form 230. A compositor, whichdescribes the composition of a type's content, are also known as itscontent model. An XML Schema typically defines three compositors thatcan be used in complex type definitions including xsd:sequence,xsd:choice, and xsd:all, for example. Compositors can include particles,which also includes components such as other compositors, elementdeclarations, wildcards, and model groups. Attribute declarations arenot considered particles because they don't repeat. Hence, attributedeclarations are not placed within a compositor but after the compositorat the end of a complex type definition, for example.

Referring now to FIGS. 3 and 4 collectively, an example transform isillustrated. FIG. 3 illustrates an exemplary XML instance file 300whereas FIG. 4 illustrates a prior art representation of an XSD file 400that describes the instance document depicted in FIG. 3. It is to beappreciated that the following examples are shown for illustrativepurposes and that the code examples shown are but one possibleconfiguration. As can be appreciated, a plurality of applications can bedesigned that are different than the specific example code fragmentsshown.

FIG. 3 illustrates an example instance document having XML elements thatare nested as the following XML example:

po.xml purchaseOrder  (see reference numeral 310)  shipTo   name  street   city   state  (see reference numeral 320)   zip  billTo  name   street   street   city  (see reference numeral 330)   province  postalcode  comment  items   item    productName    quantity   USPrice    comment   item    productName    quantity    USPrice   shipDate

The nesting illustrated in the file 300 reflects the structure of thedata—e.g., this purchase order has ship-to & bill-to addresses, acomment, and a list of items each with name, quantity, price, and soforth. However if the accompanying XML Schema file is observed,(po.xsd), the following example structure 400 is provided in prior artFIG. 4:

schema  annotation   documentation  element purchaseOrder(of typePurchaseOrderType) (see reference numeral 410)  element comment(of typestring)  complexType PurchaseOrderType (see reference numeral 420)  sequence    element shipTo(of type Address)    element billTo(of typeAddress)    element comment(of type ref)    element items(of type Items)  attribute orderDate  complexType Address (see reference numeral 430)  sequence    element name(of type string)    element street(of typestring)    element city(of type string)    choice (see reference numeral440)     sequence      element province(of type string)      elementpostalcode(of type string)     sequence      element county (of typestring)      element postcode (of type string)     sequence      elementstate(of type string)      element zip(of type positiveInteger)  attribute country  complexType Items (see reference numeral 450)  sequence    element item     complexType (see reference numeral 460)     sequence       element productName(of type string)       elementquantity        simpleType         restriction(of type positiveInteger)         maxExclusive       element USPrice(of type decimal)      element comment(of type ref)       element shipDate(of type date)     attribute partNum(of type SKU)  simpleType SKU   restriction(oftype string)    pattern

In this example, the structure of the purchase order XML file 300 is notmirrored in the XML schema file 400 that describes it. For example, thedescription of a purchaseOrder element 310 in FIG. 3 is split across theXML schema definitions shown at reference numerals 410, 420, 430, and450 of FIG. 4. Furthermore, each nested sequence, choice, or allcompositor adds one level of indentation to the leaf elements province,postalcode, county, postcode, state, and zip in the XML schemadefinition shown at reference numeral 440. However, in the purchaseorder XML file 300, these elements are immediate children of shipTo andbillTo and are at the same (or similar) indention level as siblingelements name, street, and city shown at reference numerals 320 and 330.Generally, existing tools render the XML schema structures 410-450 asseparate graphical elements with lines or boxes reflecting therelationships between them, which obscure the structure contained in thefile 300 of FIG. 3. Existing tools render the indentation level ofelements to match the source XML schema rather than the indentationlevel of the target xml instance document.

Turning to FIG. 5, a simplified graphical representation 500 provides aviewing structure similar in graphical form to the instance documentdepicted in FIG. 3. The prior art structure depicted in FIG. 2 istransformed in to the structure of FIG. 5 by expanding type definitionsand references in-line and by aligning sibling elements at the same (orsimilar) indentation level to more accurately reflect the shape of theXML data depicted in FIG. 3. For example, if the user desired to renderthe purchaseOrder element, a graphical view with the following structurecan be displayed as shown in FIG. 5:

Simplified XML Schema structure:

element purchaseOrder(of type PurchaseOrderType)  attribute orderDate element shipTo(of type Address) (see reference numeral 510)   elementname(of type string)   element street(of type string)   element city(oftype string)   element province(of type string) (see reference numeral520)   element postalcode (of type string)   element county(of typestring) (see reference numeral 530)   element postcode(of type string)  element state(of type string) (see reference numeral 540)   elementzip(of type positiveInteger)  element billTo(of type Address) (seereference numeral 550)   element name(of type string)   elementstreet(of type string)   element city(of type string)   elementprovince(of type string)   element postalcode (of type string)   elementcounty(of type string)   element postcode(of type string)   elementstate(of type string)   element zip(of type positiveInteger)  elementcomment(of type string) (see reference numeral 560)  element items(oftype Items)   element item (sequence) (see reference numeral 570)   attribute partNum(of type SKU)    element productName(of type string)   element quantity (restricted to positiveInteger)    elementUSPrice(of type decimal)    element comment (optional, of type string)   element shipDate (optional, of type date)

In general, the Address complex type that describes the shape of theshipTo & billTo elements is in-lined where it is used at referencenumerals 510 and 530. The nested sequence and choice compositors from440 of FIG. 4 are hidden such that elements province, postalcode,county, postcode, state, & zip are at the same indentation level assibling elements name, street, and city as illustrated at referencenumerals 520 through 540 of FIG. 5. The anonymous type defined at 460 ofFIG. 4 is in-lined directly into reference numeral 560, and the commentelements at reference numerals 560 and 570 have the respective stringtype in-lined.

Overall, the shape of the structure shown in the representation 500retains the desired information shown in FIG. 4, while more accuratelyreflecting the XML data in FIG. 3 and therefore being easier tounderstand. The rendering in representation 500 hides the respectivecompositors, but an alternate rendering which reveals the compositorsand still preserves the indentation rules described above is shown inFIG. 6.

Referring to FIG. 6, an alternative simplified graphical representation600 is illustrated that provides a viewing structure similar ingraphical form to the instance document depicted in FIG. 3. Compositorssuch as sequence and choice are illustrated at 610 and 620 respectively.These are shown in a different graphical orientation so as to stillmaintain the underlying form of the instance document. The alternativegraphical representation 600 appears as follows:

Referring to FIG. 7, another example XML document 700 is shown forillustrative purposes. The document 700 shows an alternative example tothe file 200 shown above in FIG. 3 and represents a full purchase orderlisting as follows.

<?xml version=“1.0”?> <purchaseOrder orderDate=“1999-10-20”>  <shipTo>  <name>Alice Smith</name>   <street>123 Maple Street</street>  <city>Mill Valley</city>   <state>CA</state>   <zip>90952</zip> </shipTo>  <billTo>   <name>Robert Smith</name>   <street>8 OakAvenue</street>   <street>Apt. #3-A</street>   <city>Old Town</city>  <province>BC</province>   <postalcode>V6B 1H6</postalcode>  </billTo> <comment>Hurry, my lawn is going wild!</comment>  <items>   <itempartNum=“872-AA”>    <productName>Lawnmower</productName>   <quantity>1</quantity>    <USPrice>148.95</USPrice>   <comment>Confirm this is electric</comment>   </item>   <itempartNum=“926-AA”>    <productName>Baby Monitor</productName>   <quantity>1</quantity>    <USPrice>39.98</USPrice>   <shipDate>1999-05-21</shipDate>   </item>  </items> </purchaseOrder>

The following code example shows again a prior art representation of theXSD data associated with the file 700 that has not been processed intosimplified graphical form via the transform components described above.As can be observed, the file dose not maintain similar indentations orother structural similarity to the underlying instance file 700.

<xsd:schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema”> <xsd:annotation>   <xsd:documentation xml:lang=“en”>    Purchase orderschema for Example.com.    Copyright 2000 Example.com. All rightsreserved.   </xsd:documentation>  </xsd:annotation>  <xsd:elementname=“purchaseOrder” type=“PurchaseOrderType”/>  <xsd:elementname=“comment” type=“xsd:string”/>  <xsd:complexTypename=“PurchaseOrderType”>   <xsd:sequence>    <xsd:element name=“shipTo”type=“Address”/>    <xsd:element name=“billTo” type=“Address”/>   <xsd:element ref=“comment” minOccurs=“0”/>    <xsd:elementname=“items” type=“Items”/>   </xsd:sequence>   <xsd:attributename=“orderDate” type=“xsd:date”/>  </xsd:complexType>  <xsd:complexTypename=“Address”>   <xsd:sequence>    <xsd:element name=“name”type=“xsd:string”/>    <xsd:element name=“street” type=“xsd:string”minOccurs=“1” maxOccurs=“3”/>    <xsd:element name=“city”type=“xsd:string”/>    <xsd:choice>     <xsd:sequence>     <xsd:annotation>       <xsd:documentation>Canadian address      </xsd:documentation>      </xsd:annotation>      <xsd:elementname=“province” type=“xsd:string”/>      <xsd:element name=“postalcode”type=“xsd:string”/>     </xsd:sequence>     <xsd:sequence>     <xsd:annotation>       <xsd:documentation>Great Britian address      </xsd:documentation>      </xsd:annotation>      <xsd:elementname=“county” type=“xsd:string”/>      <xsd:element name=“postcode”type=“xsd:string”/>     </xsd:sequence>     <xsd:sequence>     <xsd:annotation>       <xsd:documentation>United States address      </xsd:documentation>      </xsd:annotation>      <xsd:elementname=“state” type=“xsd:string”/>      <xsd:element name=“zip”type=“xsd:positiveInteger”/>     </xsd:sequence>    </xsd:choice>  </xsd:sequence>  </xsd:complexType>  <xsd:complexType name=“Items”>  <xsd:sequence>    <xsd:element name=“item” minOccurs=“0”   maxOccurs=“unbounded”>     <xsd:complexType>      <xsd:sequence>      <xsd:element name=“productName” type=“xsd:string”/>      <xsd:element name=“quantity”>        <xsd:simpleType>        <xsd:restriction base=“xsd:positiveInteger”>         <xsd:maxExclusive value=“100”/>         </xsd:restriction>       </xsd:simpleType>       </xsd:element>       <xsd:elementname=“USPrice” type=“xsd:decimal”/>       <xsd:element ref=“comment”minOccurs=“0”/>       <xsd:element name=“shipDate” type=“xsd:date”      minOccurs=“0”/>      </xsd:sequence>      <xsd:attributename=“partNum” type=“SKU”      use=“required”/>     </xsd:complexType>   </xsd:element>   </xsd:sequence>  </xsd:complexType>  <!-- StockKeeping Unit, a code for identifying products -->  <xsd:simpleTypename=“SKU”>   <xsd:restriction base=“xsd:string”>    <xsd:patternvalue=“\d{3}−[A-Z]{2}”/>   </xsd:restriction>  </xsd:simpleType>    </xsd:schema>

FIG. 8 illustrates an exemplary process 800 for transforming data to asimplified graphical representation. While, for purposes of simplicityof explanation, the process is shown and described as a series or numberof acts, it is to be understood and appreciated that the subjectprocesses are not limited by the order of acts, as some acts may, inaccordance with the subject processes, occur in different orders and/orconcurrently with other acts from that shown and described herein. Forexample, those skilled in the art will understand and appreciate that amethodology could alternatively be represented as a series ofinterrelated states or events, such as in a state diagram. Moreover, notall illustrated acts may be required to implement a methodology inaccordance with the subject processes described herein.

Proceeding to 812 of FIG. 8, a schema file or document is received forprocessing. The schema file can be an XSD structure that describes arelated XML instance file. As noted above, other types of transforms arepossible where an input file in a more complicated format is transformedto coincide with a graphical structure in a different format. At 820,the structure of an underlying XML instance document is determined. Thiscan include processing components in the XSD file to determine whatresultant components may appear an instance or XML file. This can alsoinclude processing one or more transformation rules for how to format anXSD file to have a similar structure to an instance XML file. At 830, atransform is performed on the schema document received at 810 in orderto generate a simplified graphical structure in XSD format that mirrorsor conforms to an instance structure in XML format. At 840, thetransformed file is associated with other tools such as and editor and aviewer where further document development can occur employing thesimplified graphical structure.

In order to provide a context for the various aspects of the disclosedsubject matter, FIGS. 9 and 10 as well as the following discussion areintended to provide a brief, general description of a suitableenvironment in which the various aspects of the disclosed subject mattermay be implemented. While the subject matter has been described above inthe general context of computer-executable instructions of a computerprogram that runs on a computer and/or computers, those skilled in theart will recognize that the invention also may be implemented incombination with other program modules. Generally, program modulesinclude routines, programs, components, data structures, etc. thatperforms particular tasks and/or implements particular abstract datatypes. Moreover, those skilled in the art will appreciate that theinventive methods may be practiced with other computer systemconfigurations, including single-processor or multiprocessor computersystems, mini-computing devices, mainframe computers, as well aspersonal computers, hand-held computing devices (e.g., personal digitalassistant (PDA), phone, watch . . . ), microprocessor-based orprogrammable consumer or industrial electronics, and the like. Theillustrated aspects may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. However, some, if not allaspects of the invention can be practiced on stand-alone computers. In adistributed computing environment, program modules may be located inboth local and remote memory storage devices.

With reference to FIG. 9, an exemplary environment 910 for implementingvarious aspects described herein includes a computer 912. The computer912 includes a processing unit 914, a system memory 916, and a systembus 918. The system bus 918 couple system components including, but notlimited to, the system memory 916 to the processing unit 914. Theprocessing unit 914 can be any of various available processors. Dualmicroprocessors and other multiprocessor architectures also can beemployed as the processing unit 914.

The system bus 918 can be any of several types of bus structure(s)including the memory bus or memory controller, a peripheral bus orexternal bus, and/or a local bus using any variety of available busarchitectures including, but not limited to, 64-bit bus, IndustrialStandard Architecture (ISA), Micro-Channel Architecture (MSA), ExtendedISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB),Peripheral Component Interconnect (PCI), Universal Serial Bus (USB),Advanced Graphics Port (AGP), Personal Computer Memory CardInternational Association bus (PCMCIA), and Small Computer SystemsInterface (SCSI).

The system memory 916 includes volatile memory 920 and nonvolatilememory 922. The basic input/output system (BIOS), containing the basicroutines to transfer information between elements within the computer912, such as during start-up, is stored in nonvolatile memory 922. Byway of illustration, and not limitation, nonvolatile memory 922 caninclude read only memory (ROM), programmable ROM (PROM), electricallyprogrammable ROM (EPROM), electrically erasable ROM (EEPROM), or flashmemory. Volatile memory 920 includes random access memory (RAM), whichacts as external cache memory. By way of illustration and notlimitation, RAM is available in many forms such as synchronous RAM(SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rateSDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), anddirect Rambus RAM (DRRAM).

Computer 912 also includes removable/non-removable,volatile/non-volatile computer storage media. FIG. 9 illustrates, forexample a disk storage 924. Disk storage 924 includes, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memorystick. In addition, disk storage 924 can include storage mediaseparately or in combination with other storage media including, but notlimited to, an optical disk drive such as a compact disk ROM device(CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RWDrive) or a digital versatile disk ROM drive (DVD-ROM). To facilitateconnection of the disk storage devices 924 to the system bus 918, aremovable or non-removable interface is typically used such as interface926.

It is to be appreciated that FIG. 9 describes software that acts as anintermediary between users and the basic computer resources described insuitable operating environment 910. Such software includes an operatingsystem 928. Operating system 928, which can be stored on disk storage924, acts to control and allocate resources of the computer system 912.System applications 930 take advantage of the management of resources byoperating system 928 through program modules 932 and program data 934stored either in system memory 916 or on disk storage 924. It is to beappreciated that various components described herein can be implementedwith various operating systems or combinations of operating systems.

A user enters commands or information into the computer 912 throughinput device(s) 936. Input devices 936 include, but are not limited to,a pointing device such as a mouse, trackball, stylus, touch pad,keyboard, microphone, joystick, game pad, satellite dish, scanner, TVtuner card, digital camera, digital video camera, web camera, and thelike. These and other input devices connect to the processing unit 914through the system bus 918 via interface port(s) 938. Interface port(s)938 include, for example, a serial port, a parallel port, a game port,and a universal serial bus (USB). Output device(s) 940 use some of thesame type of ports as input device(s) 936. Thus, for example, a USB portmay be used to provide input to computer 912 and to output informationfrom computer 912 to an output device 940. Output adapter 942 isprovided to illustrate that there are some output devices 940 likemonitors, speakers, and printers, among other output devices 940 thatrequire special adapters. The output adapters 942 include, by way ofillustration and not limitation, video and sound cards that provide ameans of connection between the output device 940 and the system bus918. It should be noted that other devices and/or systems of devicesprovide both input and output capabilities such as remote computer(s)944.

Computer 912 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)944. The remote computer(s) 944 can be a personal computer, a server, arouter, a network PC, a workstation, a microprocessor based appliance, apeer device or other common network node and the like, and typicallyincludes many or all of the elements described relative to computer 912.For purposes of brevity, only a memory storage device 946 is illustratedwith remote computer(s) 944. Remote computer(s) 944 is logicallyconnected to computer 912 through a network interface 948 and thenphysically connected via communication connection 950. Network interface948 encompasses communication networks such as local-area networks (LAN)and wide-area networks (WAN). LAN technologies include Fiber DistributedData Interface (FDDI), Copper Distributed Data Interface (CDDI),Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WANtechnologies include, but are not limited to, point-to-point links,circuit switching networks like Integrated Services Digital Networks(ISDN) and variations thereon, packet switching networks, and DigitalSubscriber Lines (DSL).

Communication connection(s) 950 refers to the hardware/software employedto connect the network interface 948 to the bus 918. While communicationconnection 950 is shown for illustrative clarity inside computer 912, itcan also be external to computer 912. The hardware/software necessaryfor connection to the network interface 948 includes, for exemplarypurposes only, internal and external technologies such as, modemsincluding regular telephone grade modems, cable modems and DSL modems,ISDN adapters, and Ethernet cards.

FIG. 10 is a schematic block diagram of a sample-computing environment1000 that can be employed. The system 1000 includes one or moreclient(s) 1010. The client(s) 1010 can be hardware and/or software(e.g., threads, processes, computing devices). The system 1000 alsoincludes one or more server(s) 1030. The server(s) 1030 can also behardware and/or software (e.g. threads, processes, computing devices).The servers 1030 can house threads to perform transformations byemploying the components described herein, for example. One possiblecommunication between a client 1010 and a server 1030 may be in the formof a data packet adapted to be transmitted between two or more computerprocesses. The system 1000 includes a communication framework 1050 thatcan be employed to facilitate communications between the client(s) 1010and the server(s) 1030. The client(s) 1010 are operably connected to oneor more client data store(s) 1060 that can be employed to storeinformation local to the client(s) 1010. Similarly, the server(s) 1030are operably connected to one or more server data store(s) 1040 that canbe employed to store information local to the servers 1030.

What has been described above includes various exemplary aspects. It is,of course, not possible to describe every conceivable combination ofcomponents or methodologies for purposes of describing these aspects,but one of ordinary skill in the art may recognize that many furthercombinations and permutations are possible. Accordingly, the aspectsdescribed herein are intended to embrace all such alterations,modifications and variations that fall within the spirit and scope ofthe appended claims. Furthermore, to the extent that the term “includes”is used in either the detailed description or the claims, such term isintended to be inclusive in a manner similar to the term “comprising” as“comprising” is interpreted when employed as a transitional word in aclaim.

1. A software development system including at least one processor, thesoftware development system comprising: a transform component configuredto convert a schema file into a simplified graphical data representationthat coincides with a data representation associated with an underlyinginstance document; and a viewing component configured to display thesimplified graphical data representation, wherein the simplifiedgraphical data representation maintains indentations that correspond tothe data representation associated with the underlying instancedocument, and wherein the viewing component is further configured todisplay a layered set of compositor elements in a view of the simplifiedgraphical data representation including in-line expanded typedefinitions and references in-line, and aligned sibling elements at anindentation level that reflects a shape of the underlying instancedocument.
 2. The software development system of claim 1, wherein thetransform component is configured to convert the schema file into thesimplified graphical data representation at least in part by removinglanguage constructs present in the schema file from the display of theviewing component.
 3. The software development system of claim 1,wherein the underlying instance document is associated with anExtensible Markup Language (XML).
 4. The software development system ofclaim 1, further comprising a component configured to remove compositorelements from a display representation of the simplified graphical datarepresentation.
 5. The software development system of claim 4, furthercomprising a control component configured to display the compositorelements in the simplified graphical data representation.
 6. Thesoftware development system of claim 1, wherein the transform componentis configured to expand one or more type definitions and type referencesin-line.
 7. The software development system of claim 6, wherein thetransform component is configured to align sibling elements at anindentation level that reflects a shape of an underlying instancedocument.
 8. The software development system of claim 6, furthercomprising a component configured to align anonymous types.
 9. Thesoftware development system of claim 6, further comprising a componentconfigured to align string types.
 10. The software development system ofclaim 1, wherein the transform component and the viewing component areprovided as part of an Integrated Development Environment (IDE).
 11. Thesoftware development system of claim 10, wherein the IDE is configuredto provide one or more graphical user interfaces to operate thetransform component and the viewing component.
 12. The softwaredevelopment system of claim 11, wherein the IDE is configured to providecontrols for displaying or hiding compositor elements in the simplifiedgraphical data representation.
 13. A schema design method performed by aprocessor, the schema design method comprising: loading a schema fileinto a first data structure; transforming the first data structure intoa second data structure; providing, in the second data structure, agraphical view that visually coincides with a shape of an instancedocument; determining graphical indentations that correspond to a datarepresentation associated with an underlying instance document; anddisplaying, in a simplified graphical data representation including thegraphical indentations, layers of compositor elements within thegraphical indentations including in-line expanded type definitions, andreferences in-line, and aligned sibling elements at an indentation levelthat reflects the shape of the instance document.
 14. The schema designmethod of claim 13, further comprising associating the first datastructure with an Extensible Markup Language (XML) Schema DevelopmentLanguage (XSD) and mirroring an Extensible Markup Language (XML) datastructure in the second data structure.
 15. The schema design method ofclaim 13, further comprising hiding compositor elements from a displayrepresentation of the second data structure.
 16. The schema designmethod of claim 15, further comprising displaying the compositorelements in the second data structure.
 17. The schema design method ofclaim 15, further comprising displaying the compositor elements at adifferent display orientation from other XSD components.
 18. Acomputer-readable storage medium storing instructions executable by acomputing device to perform operations comprising: transforming a schemafile into a simplified graphical data representation that coincides witha data representation associated with an underlying instance document;including indentations corresponding to the data representation in thesimplified graphical representation; and displaying a layered set ofcompositor elements in a view of the simplified graphical datarepresentation including in-line expanded type definitions andreferences in-line, and aligned sibling elements at an indentation levelthat reflects a shape of the underlying instance document.